home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5305 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB
  1. Path: mail2news.demon.co.uk!wildcard.demon.co.uk
  2. From: Cyber Surfer <cyber_surfer@wildcard.demon.co.uk>
  3. Newsgroups: comp.lang.lisp,comp.lang.c++
  4. Subject: Re: Why garbage collection?
  5. Date: Sat, 03 Feb 96 16:11:27 GMT
  6. Organization: The Wildcard Killer Butterfly Breeding Ground
  7. Message-ID: <823363887snz@wildcard.demon.co.uk>
  8. References: <hbaker-2201961503250001@10.0.2.15> <4eae5s$66p@nz12.rz.uni-karlsruhe.de> <822675271snz@wildcard.demon.co.uk> <DM09G0.MzG.0.macbeth@cogsci.ed.ac.uk>
  9. Reply-To: cyber_surfer@wildcard.demon.co.uk
  10. X-NNTP-Posting-Host: wildcard.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.30
  12. X-Mail2News-Path: wildcard.demon.co.uk
  13.  
  14. In article <DM09G0.MzG.0.macbeth@cogsci.ed.ac.uk>
  15.            jeff@cogsci.ed.ac.uk "Jeff Dalton" writes:
  16.  
  17. > >> Just look at the technical strength of the argument that GC is not
  18. > >> "in the tradition of the C community"...
  19. > >
  20. > >Yeah, I love it. ;-)
  21. > 
  22. > But it _is_ true that GC is not in the tradition of the C community.
  23. > The argument that it's a "hidden cost" is key here.  C programmers
  24. > feel that they know what everything will do in machine terms, and
  25. > to a fair extent they are right.  (That's so despite a number of
  26. > difficulties and exceptions.)
  27.  
  28. That may be less true these days, with the widespread use of C++, for
  29. the development of Windows software. There's a lot of "hidden cost" in
  30. C++ frameworks. I don't think of these as exceptions, because of the
  31. high popularity of these development tools. It's probably the programmers
  32. who use C, but not large libraries, who are the exceptions.
  33.  
  34. Also, the future, at least for business software, looks more like
  35. being document oriented, rather than application oriented. This will
  36. introduce even more hidden costs.
  37.  
  38. > So when a allocation might do lots of collecting as well (or
  39. > whatever), and you don't really know when, that seems to move
  40. > C into the higher-level / less-in-touch-with-the-machine camp.
  41.  
  42. Exactly. The kind of APIs coming out of MS, Apple, and IBM these days
  43. look more and more high level to me. C is looking less attractive than
  44. C++, but the C++ frameworks that make complex APIs easier to handle
  45. can hide even more - which is both a feature _and_ a problem.
  46.  
  47. > >Mind you, I'm very happy with a mark/compact GC, and I found one
  48. > >in a computer science book, Fundamentals of Data Structures, by
  49. > >E Horowitz and S Sahni. While they're not anti-GC, they refer to
  50. > >Knuth and his belief that specialist languages such as Lisp and
  51. > >SNOBOL are not necessary, and that list and string processing can
  52. > >be done in any language. The languages that seem to have interested
  53. > >them tend to be PL/I, Pascal, and Fortran. Not at all like Lisp.
  54. > 
  55. > Well, surely it's true that list and string processing can be done
  56. > in (almost) any language.  I've done list processing in Basic, for
  57. > instance.  (Good Basics can, of course, do strings, so that's not
  58. > interesting.)
  59.  
  60. I've done it in Forth. In fact, implementing Forth was the first time
  61. I use used linked lists. Since then, I've looked for better ways (i.e.
  62. better languages) for handling lists. The same applies to strings,
  63. as I wrote my first string package in Forth. Hmmm. That was also my
  64. first compiler...
  65.  
  66. > But there's a difference between a language is not necessary
  67. > and saying it's not valuable, or not worth having and using.
  68. > I'm not sure when Knuth stated this belief, but such points had
  69. > a different role in the past then they tend to do today,
  70. > because it was not so widely known that, or how, you could
  71. > do list or string processing.
  72.  
  73. Agreed. The book I quoted from was already dated when I first read it,
  74. in the early 80s. The Knuth quote could, for all I know, be _much_ older.
  75.  
  76. > A similar thing today (or maybe a few years back) might be to
  77. > point out that you could do object-oriented programming in
  78. > (almost) any language.
  79.  
  80. You can even do it in C++. ;-) I've not done any OOP in Forth, but
  81. there's at least one book on the subject. However, I've not read it.
  82. Perhaps you can also do functional programming in C/C++, but I've
  83. not tried it. I _have_ written an experimental Lisp to C compiler,
  84. which I should re-write someday. Anyone who has read a good Lisp
  85. tutorial (W&H, SICP, etc) should be able to write a similar compiler.
  86. -- 
  87. <URL:http://www.demon.co.uk/community/index.html>
  88. <URL:http://www.enrapture.com/cybes/namaste.html>
  89. Po-Yeh-Pao-Lo-Mi | "You can never browse enough."
  90.